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PREFACE 


The  Range  Commanders  Council  (RCC),  recognizing  the  need  for  rapid 
turnaround  support  of  range  user  requirements  and  the  efficiencies  to 
bederived  from  electronic  word  and  data  processing  sy  stems ,  has  in 
this  edition  of  the  handbook,  developed  a  Universal  Documentation 
System  (UDS)  format  adaptable  to  electronic  processing  while 
continuing  to  meet  the  needs  of  the  manual  (typewritten)  subscriber  to 
the  system. 

This  handbook  supersedes  all  previous  issues  of  RCC  document  501-79, 
volumes  1,  2 ,  3,  and  suppl emen t  2,  document  501-84.  Existing  programs 
may  use  the  previous  procedures  and  forms  as  agreed  between  the  user 
and  the  support  agency.  All  new  programs  developing  documentation 
will  use  the  procedures  and  formats  contained  in  these  volumes. 

Additional  copies  of  this  handbook  may  be  obtained  from  any  agency 
listed  in  paragraph  1.6  or  from  the 

SECRETARIAT 

RANGE  COMMANDERS  COUNCIL 

ATTN:  STEWS-SA-R 

WHITE  SANDS  MISSILE  RANGE,  NEW  MEXICO 


88002 
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CHAPTER  1 
INTRODUCTION 


1 . 1  General 

This  handbook  describes  the  Universal  Documentation  System  (UDS).  The 
DOS  is  used  to  formally  document  requesting  agency  program  support 
requirements  and  support  agency  capabilities  and  commitments  to  sup 
port  those  requirements.  The  UDS  handbook  is  published  in  three  basic 
volumes  and  a  supplement. 

Volume  1  describes  the  total  UDS  structure,  the  individual  documents 
within  the  system,  and  the  use  and  control  of  the  system. 

Volume  2  includes  sample  formats  and  describes  procedures  for  prepara¬ 
tion  of  the  Program  Introduction  (PI),  Program  Requirements  Document 
(PRD),  and  the  Operations  Requirements  (OR). 

Volume  3  includes  sample  formats  and  describes  procedures  for  Prepara¬ 
tion  of  the  Statement  of  Capability  (SC),  Program  Support  Plan  (PSP), 
and  Operations  Directive  (OD). 

A  complete  list  of  RCC  documents  pertaining  to  the  UDS  and  to 

other  documents  can  be  found  in  the  List  of  Available  Documents  ^  , 

available  through  the  RCC  Secretariat,  White  Sands  Missile  Range,  y  — 

1 . 2  Appl i cabi 1 i ty 

The  UDS  shall  be  used  by  all  agencies  desiring  support  from  agencies 
that  have  adopted  the  UDS.  Requesting  agency  requirements  documents 
and  support  agency  response  documents  will  be  prepared  in  accordance 
with  the  format  and  procedures  in  this  handbook  and  with  any  supple 
mental  instructions  prepared  by  the  support  agencies. 

1 . 3  Author i ty 

The  Documentation  Group  (DG)  of  the  Range  Commanders  Council  (RCC)  has 
the  responsibility  for  design  and  control  of  the  UDS.  The  UDS  and  the 
procedures  contained  in  this  handbook  have  been  approved  by  the  RCC. 

1.4  Handbook  Revi si  on 

Recommendations  for  revision  of  this  handbook  may  be  made  to  the  DG 
members  at  the  agencies  listed  in  Paragraph  1.6.  Recommendations  for 
revision  must  include  the  reason  for  the  change,  deletion,  or  addition 
and  a  sample  of  the  change  with  its  instructions.  The  DG  is  respon¬ 
sible  for  reviewing  the  recommendation  and,  on  approval,  for  its 
i  ncorporati on  and  implementation.  Normal  changes  do  not  require  klc 
approval;  however,  unusual  or  controvers i al  changes  may  require  RLi 
approval  at  the  discretion  of  the  DG. 
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1.5  Definitions 


Some  the  terms  that  are  frequently  used  in  this  handbook  are 
defined  next.  For  a  more  complete  listing,  refer  to  RCC  documents 

501-79,  UDS  Uniform  Test  Data  and  Data  Product  Nomenclature,  Supple¬ 
ment  1  and  502-81 ,  A  Glossary  of  Range  Termi no! ogy . 

Range/Support  Agency:  A  range/ support  agency  is  an  operational  facil¬ 
ity  that  provides  support  services  to  qualified  users  as  determined  by 
current  directives.  The  words  "range,"  "center,"  and  "support  agency" 
are  used  interchangeably. 

U s e r / Requ e s t i ng  Agency:  Any  United  States  or  foreign  government 
agency,  industrial  organization,  or  other  institution  with  authority 
to  use  range  or  support  agency  resources. 

Sponsor:  Any  element  of  a  government,  military,  or  civilian  agency 

with  authority  to  use  range  or  support  agency  resources. 

User  Requirement:  Any  item  of  support  requested  by  a  requesting 
agency  through  the  UDS. 

Derivative  Requirement:  Any  item  of  support  required  by  one  agency 
from  another  to  meet  the  first  agency's  responsibility  as  levied  by  a 
user  requirement. 

Interagency  Program:  A  program  requiring  the  participation  of  more 
than  one  range  or  support  agency. 

Lead  Range/Lead  Support  Agency:  The  range/support  agency  that  is 
responsible  for  coordinating  total  support  planning  and  operations  for 
a  particular  program,  mission,  or  test.  The  lead  range/lead  support 
agency  identifies  the  support  required  from  other  agencies  and  coordi¬ 
nates  the  total  support  effort. 

1 . 6  Information  and  Assi stance  Sources 

Prospective  users  of  the  UDS  may  obtain  assistance  in  the  preparation 
of  requirements  from  the  agencies  listed  below: 

Commanding  General 

White  Sands  Missile  Range 

Attn:  Range  Programs  Division  (NR-P) 

White  Sands  Missile  Range,  New  Mexico  88002-5113 

Commander,  U.S.  Army  Kwajalein  Atoll 
Attn:  CSSD-KT 

Post  Office  8ox  26 

APO  San  Francisco,  California  96555 

Commander,  Pacific  Missile  Test  Center 

Attn:  Range  Programs  Management  Division  (Code  3210) 

Point  Mugu,  California  93042-5000 
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Eastern  Space  and  Missile  Center 

Attn:  Directorate  of  Plans,  Programs  and  Requirements  ( XR ) 

Patrick  Air  Force  Base,  Florida  32925-5572 

Western  Space  and  Missile  Center 
Attn:  6595th  TEG/XR 

Vandenberg  Air  Force  Base,  California  93437-6021 

Air  Force  Flight  Test  Center 

Attn:  Programs  and  Requirements  (XR) 

Edwards  Air  Force  Base,  California  93523-5000 

National  Aeronautics  and  Space  Administration 
John  F.  Kennedy  Space  Center 

Attn:  NASA-Air  Force  Management  Office  (EX-NAM) 

Kennedy  Space  Center,  Florida  32899-5000 


3 


CHAPTER  2 


ORGANIZATION  AND  STRUCTURE 


2 . 1  Purpose 

The  UDS  provides  a  common  language  and  format  for  stating  requirements 
and  for  preparing  support  responses.  The  UDS  encompasses  documenta¬ 
tion  generated  by  user  agencies  which  states  program,  mission,  or  test 
requirements  and  those  response  documents  generated  by  the  support 
agencies  to  define  the  support  to  be  provided. 

2 . 2  Objectives 
The  UDS  objectives 

1.  establish  a  common  language  and  format  to  provide  more 
effective  communication  between  the  user  and  support  agency, 

2.  standardize  requirement  and  support  methodology  between  tie 
user  and  the  support  agency  to  achieve  an  effective  planning/perform¬ 
ance  i  nterf  ace  , 

3.  provide  a  standard  yet  flexible  and  dynamic  system  that  meets 
the  requirement  and  support  needs  of  both  simple  and  complex  programs. 


4.  provide  a  format  for  automation  and  manual  handling  of 
requirements  and  support  information. 

2 . 3  Concept 

The  UDS  is  intended  to  establish  standardization,  yet  be  flexible 
enough  to  be  used  by  a  number  of  different  agencies  and  to  apply  to 
both  small  and  large  programs  without  disturbing  the  basic  system 
concept.  Flexibility  permits  separate  instructions  to  be  prepared  by 
each  support  agency  for  implementation  of  the  UDS  at  that  agency. 
These  supplemental  instructions  may  contain  procedures  and  policies 
for  the  applicability  and  scope,  submission,  and  revision  of  docu¬ 
mentation. 

2 . 4  Sy  s  tern  Cr i ter i a 

The  UDS  is  based  on  a  common  structure  to  enable  users  to  employ  one 
basic  format  when  presenting  requirements  to  support  agencies.  This 
structure  is  defined  in  a  document  outline  that  combines  related 
subjects  of  the  various  program,  mission,  or  test  phases  into  a  mini¬ 
mum  number  of  broad  categories  for  simplicity  and  ease  of  understand¬ 
ing.  The  UDS  structure  relates  support  plans  to  requirements  with  a 
minimum  of  repetition. 
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The  system  provides  all  the  necessary  information  that  should  pass 
between  the  user  and  all  contributing  agencies  to  support  the  program, 
mission,  or  test.  Tne  system  is  sufficiently  flexible  to  be  used  by 
support  agencies  without  affecting  the  internal  management  of  the 
individual  agencies. 

2 . 5  Document  Organization 

The  UDS  provides  for  the  following  three  levels  of  user  and  support 
agency  documentation: 


LEVEL  USER  REQUIREMENTS  DOCUMENTS 

1  Program  Introduction  (PI) 

2  Program  Requirements 

Document  (PRD) 

3  Operations  Requirements 

(OR) 


SUPPORT  AGENCY  RESPONSE  DOCUMENTS 
Statement  of  Capability  (SC) 
Program  Support  Plan  (PSP) 

Operations  Directive  (OD) 


Level  1_.  The  Level  1  documents  (the  PI  and  SC)  are  used  to  initiate 
program  support  planning  between  users  and  support  agencies. 

Level  2_.  The  Level  2  documents  (the  PRD  and  PSP)  may  be  required  to 
provide  additional  or  more  detailed  program  information,  especially 
for  the  more  complex  programs. 

Level  3>*  The  Level  3  documents  (the  OR  and  OD)  are  used  to  plan 
individual  operations  within  a  program. 

2.5.1  Level  1  Documents 


P rog r am  I ntroducti on  (PI).  The  PI  document  is  the  initial  planning 
document  submitted  by  a  potential  user  to  the  support  agency  immedi¬ 
ately  upon  identification  of  the  scope  and  duration  of  program  activ¬ 
ity.  The  potential  user  should  submit  the  PI  using  best  available 
information,  enabling  the  support  agency  to  initiate  resource  and 
technical  planning.  This  information,  while  sometimes  fragmentary  and 
incomplete,  is  of  substantial  value  to  the  support  agency  in  determin¬ 
ing  the  scope  of  the  program.  For  many  programs,  the  PI  is  designed 
to  eliminate  further  documentation  except  for  conduct  of  specific 
operations. 

Statement  of  Capability  ( SC ) .  The  SC  document  is  the  support  agency's 
response  to  the  PI.  When  properly  signed,  the  SC  is  evidence  that  a 
program  has  been  accepted  for  support  by  the  support  agency,  subject 
to  approval  by  higher  headquarters  when  applicable.  Support  condi¬ 
tions,  qualifications  and  resources,  or  other  considerations  are  ini¬ 
tially  identified  by  this  document  and  serve  as  a  baseline  reference 
to  subsequent  acceptance  and  commitment  by  the  support  agency.  The  PI 
and  the  SC  complement  each  other  in  establishing  the  scope  of  the 
program  support  activity. 
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2.5.2  Level  2  Documents 

Program  Requi rements  Document  ( PRD ) .  The  PRD  is  prepared  by  the  range 
user  and  is  a  detailed  full  program  planning  document  normally 
required  for  complex  or  long  lead-time  programs. 

Program  Support  P 1  a n  (PSP).  The  PSP  is  a  response  to  the  requirements 
present eTi i~n  OTe  PR D  and  Ts  prepared  by  the  responsible  support 
agency . 

2.5.3  Level  .3  Documents 

Operations  Requi rements  (OR).  The  OR  document  describes  in  detail  the 
program  s  requirements  for  each  program,  mission,  specific  test,  or 
series  of  tests.  It  is  prepared  by  the  user. 

The  OD  is  the  support  agency's  response  to 
plan  for  implementation  of  support  func¬ 
tions  for  a  program,  mission,  specific  test,  or  series  of  tests. 

2 . 6  Suppl emental  Documentation 

The  UDS  includes  provisions  for  supplemental  documentation.  This 
supplemental  documentation  includes  extracts  of  selective  portions  of 
the  basic  documents  and  supplements  that  are  actually  parts  of  the 
basic  documents  but  do  not  exist  under  the  same  basic  cover  nor  follow 
the  same  management  or  distribution  pattern.  The  required  supple¬ 
mental  documentation  is  determined  by  joint  user-support  agency 
agreement  at  the  time  of  program  initiation. 

2.6.1  Document  Extracts 

Document  extracts  relate  to  derivative  requirements  where  requirements 
placed  on  a  given  support  agency  result  in  the  generation  of  addi¬ 
tional  (derivative)  requirements  that  must  be  placed  on  other  agen¬ 
cies.  Derivative  requirements  relate  to  the  lead  support  agency 
concept  where  one  agency  is  given  overall  support  responsibility  when 
the  total  support  involves  a  number  of  agencies. 

Examples  of  document  extracts  are 

Program  Requirements  Document  Extract  (PRDE).  The  PRDE  becomes 
necessary  when  requirements  which  are  placed  on  an  agency  in  turn 
create  additional  (derivative)  requirements  that  must  be  levied  on 
other  agencies.  These  requirements  occur  when  it  is  not  appropriate 
to  levy  the  original  PRD  on  these  other  agencies.  The  derivative 
requirements  are  prepared  using  PRU  formats  in  accordance  with  the 
standard  UDS  outline  in  appendix  A. 

Qperati ons  Requirements  Extract  (ORE ) .  The  ORE  is  identical  to  the 
PROE  except  that  it  applies  to  the  OR  and  relates  to  the  lead  support 
agency  concept  where  the  lead  agency  must  levy  derivative  requirements 
on  other  agencies.  In  general,  the  basic  requirements  will  be 
extracted  from  the  user's  original  OR  and  expanded  upon  by  the  lead 
agency . 


Opera ti^o ns  Directive  (OD). 
the  OR  and  Ts  t h e  d e t a i 1 e d 
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2.6.2  Section  Supplements 

Section  supplements  break  out  detailed  information  of  a  particular 
section  for  separate  distribution  and  in  general,  will  be  restricted 
to  the  larger  programs.  On  the  larger  programs,  certain  requirements 
such  as  data  formatting,  processing,  and  display  are  quite  voluminous 
and  apply  to  only  a  minority  of  people  concerned  with  the  program.  It 
is  appropriate  that  these  requirements  be  prepared  and  distributed 
under  separate  cover.  These  supplements  may  be  sections  of  either  a 
PRO,  PSP,  OR,  or  00.  They  are  stand-alone  documents  and  are  not  bound 
with  the  basic  document.  They  are,  however,  identified  as  a  section 
of  the  appropriate  document  and  retain  the  same  format  and  numbering 
system  as  described  for  Level  2  and  3  UOS  documents. 

2 . 7  Other  Documentation 

Program,  mission,  or  test  requirements  documents  in  all  instances  must 
be  understandable  and  stand  on  their  own;  however,  there  is  much 
supporting  information  that  must  be  documented  and  related  to  the 
requirements  so  that  support  may  be  provided.  Examples  of  such 
information  are  antenna  patterns,  trajectory  data,  pyrotechnics, 
explosive  forces  range  safety  procedures,  schedules,  test  operation 
procedures,  security  guides,  and  mission  rules  and  assignments.  If 
this  information  is  documented  separately,  it  should  be  referenced  in 
the  UDS  program  documentation  which  is  being  developed. 

2 . 8  Draft  Conferences 

When  PI,  PRO,  and  OR  drafts  are  prepared,  conferences  may  be  held  for 
new  programs  to  discuss  the  complexity  of  the  support  and  to  consider 
foreseeable  difficulties.  The  conferences  provide  the  opportunity  to 
begin  coordination  early,  to  discuss  security  classifications,  and  to 
assess  support  questions.  The  support  agency  distributes  the  draft 
and  advises  all  interested  user  and  support  agency  personnel  when  and 
if  they  are  required  to  attend  a  draft  conference. 

2 . 9  Document  Structure 

The  UDS  provides  for  a  building  block  concept  of  developing  and 
presenting  requirements. 

2.9.1  General 

Requirements  documents,  the  Program  Introduction  (PI),  Program 
Requirements  Document  (PRD),  and  the  Operations  Requirements  (OR)  are 
literally  extensions  of  each  other  and  are  used  exclusively  or  in 
tandem  with  each  other  depending  on  the  size  and  complexity  of  the 
program.  For  example,  the  PI  is  the  document  that  officially  intro¬ 
duces  a  program,  mission,  or  test  to  a  support  agency.  The  support 
agency,  because  of  the  size  or  complexity  of  the  program,  may  require 
that  the  PI  be  followed  by  the  PRD  and  OR  to  more  definitively  state 
requi rements  . 
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2.9.2  Document  Outline 


The  UDS  document  outline  is  a  common  numbering  system  which  provides 
for  the  standard  presentation  of  information  by  UDS  subscriber 
agencies  and  serves  as  the  framework  for  all  documents  within  the  UDS. 
Section  numbers,  (first  four  digits,  for  example,  1405)  and  associated 
titles  are  controlled  and  assigned  by  the  RCC  DG. 

The  UDS  outline  is  composed  of  the  following  major  section  groups: 

Sections  1000  -  1999  contain  Program  Administrative  and  Technical 
I nf ormati on 

Sections  2000  -  6999  contain  Test/Mission  Operational 
Requi rements 

The  UDS  Document  Outline  and  applicable  UDS  Requirements/Response 
documents  are  outlined  in  appendix  A. 

The  sections  are  structured  to  provide  a  definitive  area  in  which  to 
include  requirements  and  respective  support  agency  responses.  The 
outline,  coupled  with  pre-defined  formats  and  instructions,  contained 
in  volumes  2  and  3  of  the  UDS  serve  as  a  checklist  to  prevent  perti¬ 
nent  data  from  being  overlooked.  Only  those  UDS  sections  that  best 
suit  the  needs  of  the  particular  program,  mission,  or  test  being 
documented  need  be  used.  The  UDS  documents  need  not  be  limited  to  the 
statement  of  pure  requirements  or  responses.  Informational  data  may 
be  provided  as  deemed  necessary  to  clarify  stated  requi r erne n ts  and 
responses.  If,  however,  the  information  or  background  material  is 
voluminous,  reference  to  a  supplemental  document  should  be  considered. 
Pictures,  sketches,  or  graphics  may  also  be  provided  under  separate 
cover.  Supplemental  documentation  should  be  cross  referenced  in  the 
UDS  document. 

In  some  cases  such  as  composite  systems,  the  UDS  outline  provides  for 
a  requirement  to  be  stated  as  a  composite  system  or  as  independent 
systems.  Coordination  between  the  requesting  agency  and  the  support 
agency  will  determine  the  best  approach  for  documenting  such  require¬ 
ments.  Complex  requirements  should  be  further  broken  down  within  the 
appropriate  UDS  section  to  allow  for  simple  interpretation  and 
response  by  the  support  agency. 

Where  requirements  are  minimal,  as  in  the  case  of  small  programs,  or 
when  the  requirements  are  only  generally  defined  at  the  program 
planning  stage,  user  agency  requirements  may  be  stated  in  the  general 
section  of  each  UDS  section  or  subsection. 

2.10  Document  Implementation 

The  UDS  is  designed  to  accommodate  as  many  conditions  as  practical. 
While  it  is  most  desirable  to  have  single  Level  I  documents  (for 
example,  a  PI  and  SC  that  contain  total  program  information),  it  is 
also  acceptable  to  have  several  Pis  and  SCs.  This  latter  approach  is 
used  when  different  support  agencies  provide  support  for  unique  and 
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unrelated  phases  of  program,  mission,  or  test.  For  example,  one 
agency  supports  engine  tests  for^Program  "X,"  another  agency  provides 
on-orbit  support  for  Program  "X." 

The  same  philosophy  applies  to  Level  2  documents.  A  single  PRD  and 
PSP  will,  wherever  practical,  contain  all  program  level  information. 
However,  it  is  acceptable  to  have  multiple  PRUs  and  PSPs  as  explained 
above. 

The  most  detailed  level  of  requirements  and  support  is  contained  in 
Level  3  documents  which  describe  specific  requirements  and  support. 

The  OR/OD  documents  will  be  prepared  as  single  or  multiple  documents 
as  required  for  effective  management  at  the  user  and  support  agencies. 

The  UDS  documents  may  be  provided  by  use  of  electronic  word  and  data 
processing  systems  or  manual  (typewritten)  methods.  The  method  of 
implementation  and  the  type  and  schedule  of  documents  will  be 
negotiated  by  the  lead  support  agency  and  the  user. 

2.10.1  Standard  Formats 

Standard  UDS  formats  are  provided  for  entering  requirements  and 
support  responses.  These  formats  provide  for  all  the  necessary 
information  that  should  pass  between  the  user  and  all  contributing 
support  agencies  to  support  the  program,  mission,  or  test.  Standard 
formats  also  provide  for  standardization  of  requirements  presentation 
and  ensure  proper  i nterpretati on  and  response.  Only  those  standard 
formats  that  best  suit  the  requirements  of  the  particular  program  or 
test/mission  need  be  us°d. 

2.10.2  Format  Identification 

Approved  UDS  formats  are  identified  for  each  UDS  section.  Format 
numbers  are  assigned  by  the  RCC  DG  for  each  UDS  section  format  and  are 
identified  by  using  the  corresponding  section  number  for  each  format. 
The  UDS  Sections  1000  through  6999  are  used.  Exception  is  made  for  a 
general  purpose  format  as  explained  below. 

Format  numbers  are  assigned  for  the  PI  and  SC  for  each  section  and  are 
individually  identified  in  the  lower  right  portion  of  the  format 
adjacent  to  the  classification  line  in  the  following  manner: 

UDS  1010  PI  UDS  1010  SC 

(Date  of  Approval)  (Date  of  Approval) 

A  multi  purpose  general  format  is  provided  for  the  PI  and  SC  and  may 
be  used  to  supplement  or  extend  information  or  requirements.  The 
general  format  is  identified  in  the  lower  right  portion  of  the  format 
adjacent  to  the  classification  line  in  the  following  manner: 

UDS  GEN  PI  UDS  GEN  SC 

(Date  of  Approval)  (Date  of  Approval) 
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The  format  numbers  for  PRD/OR  formats  (R=REQUIREMENTS )  and  PSP/OD 
formats  (S=SUPP0RT)  are  assigned  for  each  section  and  are  individually 
identified  in  the  lower  right  portion  of  the  format  adjacent  to  the 
classification  line  in  the  following  manner: 


UDS  1010  R  UDS  1010  S 

(Date  of  Approval)  (Date  of  Approval) 

A  multipurpose  general  format  is  provided  for  the  PRD/OR  and  PSP/OD 
and  may  be  used  to  supplement  or  extend  information  or  requirements. 
The  general  format  is  identified  in  the  lower  right  portion  of  the 
format  adjacent  to  the  classification  line  in  the  following  manner: 

UDS  GEN  R  UDS  GEN  S 

(Date  of  Approval)  (Date  of  Approval) 

The  month  and  year  of  format  approval  by  the  RCC  DG  is  printed  below 
the  format  number. 

Approved  UDS  formats  for  PSP/OD  use  shall  be  numbered  to  correspond  to 
the  PRO/OR  format  to  which  it  responds.  For  example,  when  format  1040 
R  is  used  in  PRD  Section  1040,  the  format  for  PSP  Section  1040  shall 
bear  the  number  1040  S.  The  PRD/OR  and  PSP/OD  formats  need  not  be 
identical,  but  may  be  the  same  depending  on  the  type  of  response  data 
to  be  entered.  Exception  is  made  for  the  multipurpose  general  format 
previously  explained. 

2.11  Security  Classification 

The  safeguarding  of  classified  information  is  the  mutual  responsi¬ 
bility  of  all  personnel.  Adherence  to  the  related  and  established 
security  procedures  is  mandatory.  Details  for  the  proper  handling  of 
classified  documents  are  found  in  the  applicable  agency  security 
guides,  manuals,  and  regulations. 

The  originating  agency  of  a  UDS  document  is  responsible  for  identi¬ 
fying  the  information  to  be  protected  including  application  of  the 
proper  security  classification  designators  and  any  other  special  secu¬ 
rity  markings  required.  When  the  classified  sections  of  large  docu¬ 
ments  are  few  in  number,  it  may  be  expedient  to  provide  unclassified 
basic  documents  with  the  classified  portions  provided  in  a  separate 
classified  document  extract.  Classified  extracts  will  have  limited 
distribution  and  be  subject  to  the  control  imposed  by  their  classifi¬ 
cation.  Classified  extracts  should  be  cross  referenced  in  the  basic 
unclassified  document. 

2.12  Document  Revision 

A  revision  is  considered  to  be  any  information  added,  deleted,  or 
revised  in  any  section  of  a  UDS  document.  Revisions  may  be  made 
either  by  preparing  a  completely  new  document  or  by  submitting  the 
revised  information.  In  any  case,  users  are  requested  to  discuss  all 
proposed  revision  with  the  lead  support  agency.  Pen  and  ink  revisions 
submitted  by  letter  are  permissible  for  small  changes;  however,  the 
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changes  should  be  incorporated  into  the  next  revision  to  the  document. 
The  UDS  documents  will  reflect  the  revision  number  and  date  of  the 
revision.  Revisions  shall  be  numbered  consecutively  beginning  at  01. 
It  is  recommended  that  the  basic  document  be  reissued,  incorporating 
all  revisions  when  the  number  of  revisions  cause  the  document  to  be 
unmanageable.  The  Revision  Control  Section  1031  will  be  used  to 
identify  the  scope  of  the  revision  and  shall  be  transmitted  with  any 
revised  pages.  Section  1030  also  provides  a  historical  record  of 
revisions  made  to  the  document.  In  some  automated  systems,  the  date 
of  the  revision  may  be  used  in  lieu  of  the  revision  number. 

The  use  of  the  symbol  "R“  in  column  72  to  identify  revised  lines  in  a 
format  is  encouraged  and  should  be  used  whenever  practical.  In  sub¬ 
sequent  revisions  of  a  section,  delete  all  Rs  applicable  to  the  pre¬ 
ceding  revision. 

2.13  Document  Reproduc ti on 

The  documents  prepared  by  the  user  must  be  of  reproducible  quality. 

2.14  Document  Distribution 

Each  document  should  contain  its  own  document  distribution  (UDS  1020) 
section.  This  section  lists  the  agencies  or  activities  to  receive  the 
document  and  the  number  of  copies  each  should  receive.  The  user  will 
identify  distribution  for  requirements  documents;  support  activities 
will  normally  cover  the  distribution  in  the  requirements  document  plus 
any  distribution  peculiar  to  operating  elements  for  the  required 
support.  Internal  organization  sub  levels  not  appropriate  for 
inclusion  in  the  1020  section  may  be  included  elsewhere  with  the 
document  as  referenced  in  the  1020  section. 

2.15  Document  Cancellation 

The  user  or  originator  notifies  the  lead  support  agency  by  letter  when 
a  PI,  PRD,  or  OR  is  to  be  canceled.  The  notice  includes  the  title, 
number,  and  date  of  the  document.  Cancellation  of  the  requirements 
document  automatically  cancels  the  corresponding  support  document. 

The  lead  support  agency  is  responsible  for  notifying  recipients  of  the 
cancel lations. 

2.16  Document  Disposition 

The  official  file  copy  will  be  maintained  and  retired  by  the  respon¬ 
sible  agency  in  accordance  with  applicable  records  disposition  direc¬ 
tives.  All  other  copies  may  be  destroyed  upon  completion  or  cancella¬ 
tion  of  the  program.  Computerized  copy,  disks,  diskettes,  or  tapes 
will  be  handled  as  prescribed  bylocal  regulations  for  storage  or 
processing. 
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CHAPTER  3 


USER  AGENCY  REQUIREMENTS  DOCUMENTATION 


3 . 1  General 

Requirements  documents  (Program  Introduction  (PI),  Program  Require¬ 
ments  document  (PRD),  and  Operations  Requirements  (OR))  are  prepared 
by  the  user  agency  according  to  a  schedule  negotiated  by  the  lead 
agency  and  user.  The  support  agency  normally  takes  the  lead  in  sched¬ 
ule  establishment  because  it  is  the  most  knowledgeable  with  respect  to 
support  acquisition  and  implementation.  The  requirements  for  a  pro¬ 
gram,  mission,  or  test  are  included  in  a  PI,  PRD  or  OR,  or  in  combina¬ 
tions  as  the  program,  mission,  or  test  size  dictate.  The  initial 
issue  of  each  document  includes  the  information  needed  to  present  the 
requirements  which  are  known  at  the  time  of  issue.  Emphasis  should 
initially  be  placed  on  identifying  requirements  which  call  for  long- 
range  planning  action  even  though  detailed  use  or  implementation 
details  may  not  be  known.  As  more  information  becomes  available, 
revisions  are  made  to  incorporate  the  additional  data.  The  prime 
consideration  is  to  ensure  the  earliest  possible  receipt  of  require¬ 
ment  information  at  the  support  agency. 

The  user  should  make  every  effort  to  ensure  that  the  requirements 
documentation  is  sufficient  in  scope  to  include  all  known  and  antici¬ 
pated  program  requirements.  For  this  reason,  an  accepted  PI,  PRD,  or 
OR  should  be  revised  when  there  is  a  significant  change  in  the  user's 
program.  For  example,  changes  in  such  items  as  program  scope,  mile¬ 
stone  dates,  test  vehicle  characteristics,  operating  or  launch  loca¬ 
tions,  and  support  requirements  require  document  revision. 

The  user  is  responsible  for  ensuring  that  requirements  are  promptly 
submitted  at  the  request  of  the  support  agency  and  in  accordance  with 
scheduled  lead  times  to  allow  for  planning,  funding,  software  develop¬ 
ment,  and  construction;  that  requirements  documents  reflect  all  major 
requirements;  that  all  requirements  are  necessary  to  meet  the  program, 
mission/test  objectives;  and  that  all  requirements  have  been  offi¬ 
cially  approved  and  signed.  The  user  is  also  responsible  for  ensuring 
that  each  requirements  document  contains  a  Section  1020  -  Distribution 
List,  and  that  the  list  identifies  the  number  of  copies  needed  to 
fulfill  the  user  organization  distribution  requ i rements.  Following 
initial  distribution,  the  user  is  responsible  for  all  additional 
cop i es . 

3 . 2  Support  Agency  Rev i ew 

Support  agencies  will  review  requirements  documents  received  from  the 
user.  Acceptance  by  the  support  agency  is  dependent  upon  adequacy  of 
information  and  format.  Acceptance  by  a  support  agency  also  directs 
the  staff  and  operating  elements  of  the  support  organization  to  pre¬ 
pare  the  response  documents  and  necessary  plans  for  support. 
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Support  agencies  shall  assign  a  document  number,  establish  a  suspense 
date  for  the  publication  of  the  resulting  support  documentation, 
notify  the  various  support  organizations  of  the  suspense  date,  and 
publish  requirements  document  extracts  and  support  documentation.  The 
support  agency  will  also  supplement  user  documentation  distribution 
lists.  If  further  documentation  is  required,  the  support  agency  may 
provide  the  user  with  a  block  of  numbers  to  identify  these  documents. 

3 . 3  Ob jecti ves  Categor i es  and  Requi rements  Classes 

Support  agency  resources  and  support  agency  development  are  planned 
and  based  on  valid  support  requirements  submitted  by  the  user.  The 
requirements  are  those  needed  to  meet  user  program,  mission,  or  test 
objectives.  To  ensure  that  requirements  will  be  met,  the  user  must 
determine  the  objectives  category  and  the  requirements  class 
(accuracy)  and  relate  these  to  basic  user  needs.  Because  these  objec¬ 
tives  and  accuracy  requirements  are  vital  to  support  agency  planning 
and  development,  it  is  necessary  to  precisely  define  categories  of 
objectives  and  classes  of  accuracies  as  well  as  to  establish  discrete 
levels  of  priorities  that  relate  to  these  objectives  and  accuracies. 

3.3.1  Objectives  Categories 

The  three  objectives  categories,  I,  II,  and  III,  are  defined  next. 

Category  I.  Category  I  objectives  are  mandatory  to  the  program, 
mission,  or  test.  These  objectives  are  those  items  which  if  not 
accomplished  would  significantly  impact  program  schedules,  costs,  and 
verification  of  system  performance. 

Category  1 1 .  Category  II  objectives  are  required  to  make  the  program, 
mission,  or  test  a  complete  success  but  are  not  mandatory.  In  other 
words,  they  are  objectives  that  could  be  sacrificed  for  performance, 
cost,  time,  or  other  constraints. 

Category  III.  Category  III  objectives  are  desirable  for  such  items  as 
design  research,  environmental  research,  associated  projects,  and 
supporting  engineering  effort.  Generally,  they  are  objectives  that 
would  be  beneficial  to  meet  if  support  can  be  provided  with  existing 
support  agency  capability. 

3.3.2  Requi rements  Classes 

Requirements  classes  relate  to  accuracy  and  reflect  degrees  of 
i ns trumen ta ti on  accuracy  that  are  used  for  implementing,  planning,  and 
developing  support  agency  capability.  The  three  classes  are  described 
next. 

Class  I_.  Class  I  accuracy  represents  the  minimum  acceptable  accuracy 
values  or  integral  of  coverage  that  is  acceptable  to  the  user.  Class 
I  needs,  coupled  with  objective  priority,  are  generally  used  for 
budget  justification  planning,  engineering  planning,  and  operational 
support  planning. 
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Class  II.  Class  II  accuracy  represents  more  stringent  values  that 
would  achieve  program,  mission,  or  test  objectives  to  a  greater  degree 
of  accuracy.  Class  II  needs  are  generally  used  by  the  support  agency 
in  short-range  improvement/optimization  planning  and  implementation  to 
meet  the  more  stringent  future  requirements. 

Class  III.  Class  III  accuracy  generally  represents  the  ultimate  in 
desired  capability  as  well  as  the  state-of-the-art  requirement  used  by 
the  support  agency  in  long-range  improvement  and  development  planning. 

3.3.3  Requi rement  Pr i ori ty  Classification 

A  priority  must  be  defined  to  evaluate  requirements  on  an  overall 
program,  mission,  or  test  basis.  The  three  classifications,  defined 
next,  are  mandatory,  required,  and  desired. 

Mandatory .  A  mandatory  classification  is  the  minimum  requirement  that 
is  essential  to  achieve  program,  mission,  or  test  objectives. 

Required.  A  required  priority  is  support  that  would  materially  aid  in 
achieving  all  objectives  and  is  necessary  for  detailed  analysis  of 
system  performance. 

Des i red .  A  desired  requirement  is  any  support  which  can  be  obtained 
in  addition  to  the  mandatory  or  required  classification. 

3 . 4  Requi rements  Documentati on  Lead  T i me 

Lead  times  vary  considerably  from  program  to  program  depending  on  the 
scope  of  support  needed.  Requirements  documentation  lead  times  are 
established  by  the  user  agency  and  support  agency.  Nominal  lead 
times,  based  on  past  experience,  are  presented  below: 


INITIAL  DOCUMENTATION  SUBMISSION 
( Lead  Time  in  Years  ) 


SCOPE  OF  AUGMENTATION  NEEDED 


DESIRED 


Major  additions  requiring  new  4  1/2 

facility  construction. 

Extensive  software  development  3  1/2 

or  additions  to  instrumentation 
not  requiring  major  facility 
construction. 

Moderate  software  development  or  2 

instrumentation  additions  funded 
by  the  user. 

1 


REQUIRED 
3  1/2 

2  1/2 


1 


1/2 


Minor  software  development  or 
instrumentation  improvements. 
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Requirements  documentation  is  submitted  well  in  advance  of  the  first 
requested  support  or  test  date.  This  time  is  needed  for  the  support 
agency  to  provide  the  required  software,  facilities  or  instrumentation 
and  to  review,  accept,  approve,  publish,  and  distribute  the  necessary 
support  documentation. 

3 . 5  Requ i remen ts  Documentati on  (PI,  PRD ,  OR ) 

Requirements  documentation  is  compiled  in  accordance  with  the  general 
instructions  contained  in  chapter  2 ,  the  UDS  outline  in  appendix  A, 
the  standard  formats  and  instructions  in  volume  2,  and  the  specific 
instructions  described  next. 

3.5.1  Program  Introduction  (PI) 

The  PI  is  the  document  that  officially  introduces  a  program,  mission, 
or  test  to  a  support  agency  and  establishes  the  scope  of  program 
activity.  Within  the  defined  scope,  the  user  has  freedom  in  planning 
specified  operations  in  detail.  The  support  agency,  however,  will 
decide  if  further  detail  should  be  included  in  the  PI  or  if  more 
detailed  documentation  is  required. 

New  program  requirements  may  impose  a  need  for  additional  tracking 
coverage,  additional  data  products,  different  frequencies,  or  other 
accommodations  not  available  at  the  support  range.  The  criteria  and 
qualifications  of  such  requirements  should  be  stressed  in  the  PI. 

Users  with  programs  involving  orbital  operations  or  large  weapon 
systems  should  consider  the  program  in  phases.  Phase  examples  are 
prelaunch,  orbital,  recovery,  test  location,  development,  and  system 
components.  In  these  cases,  the  user  should  identify  in  the  PI  those 
requirements  that  differ  and  those  that  are  unique  to  a  particular 
phase.  If  a  particular  requirement  is  program-wide  and  does  not 
differ,  then  such  a  distinction  is  not  necessary. 

3.5.2  Program  Requi rements  Document  ( P RD  ) 

The  PRD,  as  a  detailed  program  planning  document,  contains  the  user's 
desired  support  requirements  from  the  support  agency  and  may  contain 
supplemental  information  needed  for  clarity.  The  need  for  a  PRD  is 
determined  during  the  analysis  of  the  PI  or  during  early  planning 
meetings  and  will  be  stated  in  the  SC.  A  PRO  is  submitted  immediately 
when  identified.  The  user  should  not  delay  submittal  of  the  PRD 
because  of  incomplete  knowledge  of  support  requirements.  If  required 
by  the  support  agency,  the  PRD  is  submitted  by  the  user  agency 
according  to  a  schedule  negotiated  by  the  lead  agency  and  the  user. 

3.5.3  Operations  Requi rements  ( OR )  Document 

The  OR  document  is  a  mission-oriented  document  that  describes  in 
detail  the  program's  requirements  for  each  program,  mission,  specific 
test,  or  series  of  tests  and  is  prepared  by  the  user.  The  PRD  and  OR 
must  be  complete  documents  capable  of  standing  alone.  The  OR  must  not 
reflect  new  requirements  that  were  not  previously  stated  in  the  PI  and 
PRD.  The  OR  format  must  be  consistent  with  the  UDS  outline  in 
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appendix  A  and  the  formats  in  volume  2.  If  the  OR  is  required  by  the 
support  agency,  it  is  submitted  by  the  user  agency  according  to  a 
schedule  negotiated  by  the  lead  agency  and  user. 

3 . 6  Requ i rements  for  Support  Agencies 

Section  6020  of  the  UDS  is  used  for  imposing  support  requirements  on 
other  agencies  in  interrange  operations  and  is  mainly  used  by  a  lead 
support  agency.  When  prepared  by  a  lead  support  agency,  section  6020 
is  added  to  the  requirements  document  before  distribution.  If  the 
lead  support  agency  requires  support  from  more  than  one  agency,  a 
separate  section  6020  will  be  prepared  for  each.  When  prepared  by  a 
support  agency  other  than  the  lead  agency,  the  additional  information 
will  be  added  to  the  lead  support  agency  attachment.  Pages  added  by  a 
supporting  agency  will  continue  the  numbering  sequence  initiated  by 
the  lead  agency. 

Extracts  of  the  PRD/0R  are  prepared  by  the  support  agency  when 
requirements  are  such  that  planning  support  must  be  accomplished 
before  authorization  to  acquire  a  capability  is  given.  The  extract 
documents  relate  to  derivative  requirements  where  requirements  placed 
on  a  lead  support  agency  result  in  additional  (derivative)  require¬ 
ments  that  must  be  placed  on  other  agencies.  Derivative  requirements 
relate  to  the  lead  support  agency  concept  where  one  agency  is  given 
overall  support  responsibility  when  the  total  support  involves  a 
number  of  agencies  (refer  to  chapter  4). 
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CHAPTER  4 


SUPPORT  AGENCY  RESPONSE  DOCUMENTATION 


4 . 1  General 

This  chapter  pertains  specifically  to  support  agency  documentation  and 
supplements  the  information  contained  in  chapter  2.  Support  agency 
response  documents  (Statement  of  Capability  (SC),  Program  Support  Plan 
(PSP),  and  the  Operations  Directive  ( 0  D )  )  are  prepared  by  the  support 
agency  in  response  to  the  approved  requirements  prepared  and  submitted 
by  the  user  agency.  Response  documents  are  revised  by  the  support 
agency  when  requirements  are  changed  or  support  is  revised. 

4 . 2  Support  Documen  tati on  ( SC  ,  PSP,  QD  ) 

The  following  subparagraphs  describe  the  Statement  of  Capability, 
Program  Support  Plan,  and  Operations  Directive. 

4.2.1  Statement  of  Capability  ( SC ) 

The  SC  provides  a  response  to  the  user's  PI.  The  PI,  in  combination 
with  the  approved  SC,  forms  a  basic  agreement  between  the  user  and  the 
support  agency  and  guides  the  more  detailed  planning  directives  to 
support  organizations. 

Wherever  possible,  the  SC  responds  to  the  PI  on  an  i tem-f or-i tern 
basis.  Responses  may  be  presented  in  the  general  section  of  each  UDS 
section  or  subsection  when  further  breakdown  is  not  warranted.  In 
some  cases,  the  support  agency  may  respond  to  the  PI  on  an  exception 
basis  rather  than  with  a  definitive  support  plan.  Also  at  the 
discretion  of  the  support  agency,  commonly  supplied  items  and 
requirements  that  can  be  satisfied  with  existing  capability  may  be 
answered  in  a  general  all-inclusive  statement.  The  approach  taken 
depends  generally  on  the  nature  and  the  purpose  of  the  program. 

When  the  support  agency  capability  will  not  meet  the  requirements 
stated  in  the  PI,  the  SC  specifies  such  restraints  and  1 imi tations. 

The  SC  may  also  serve  to  support  funding  policy  directives,  and  assign 
existing  facilities  such  as  launch  complexes,  office  space,  assembly, 
and  storage  areas  available  to  meet  requirements  stated  in  the  PI.  If 
the  user  requires  new  construction,  the  SC  may  provide  site  approval 
by  the  support  agency. 

4.2.2  Program  Support  Plan  (PSP) 

The  PSP  is  the  support  agency's  response  to  the  PRD.  The  initial  PSP 
issue  includes  an  i tem-f or-i tern  response  to  the  program  requirements 
which  are  known  at  the  time  of  issue  and  stated  in  the  PRD.  The  PSP 
formats  and  instructions  provided  in  this  handbook  are  designed  simi¬ 
larly,  to  the  PRD  to  provide  parallel  association  between  the  require¬ 
ments  and  the  support  responses. 
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The  PSP  document,  when  designed  by  the  support  agency  using  the  UQS 
formats,  may  be  short  or  long  in  content.  Short  document  content 
includes  only  those  sections  essential  for  conveying  the  requirements 
and  for  confirming  the  support.  Short  documents  may  contain  only  a 
few  sections  related  to  administration  and  document  control  followed 
Dy  Section  2030  -  Support  Commitment  and  Section  2060  -  Support 
Requirements  Which  Cannot  Be  Met.  Section  2080  -  Requester's  Respon¬ 
sibilities,  and  any  others  such  as  Section  2070  -  Engineering  Plans 
and  Schedules  may  also  be  included.  Routine  boiler  plate  material 
which  may  be  program  common  knowledge  is  usually  reflected  in  a  well- 
developed  PRO. 

Long  document  content  includes  all  necessary  document  responses  and  is 
not  simply  limited  to  a  statement  of  the  support  to  be  provided. 

Enough  background  material  will  be  included  so  the  manner  in  which  the 
requirements  are  going  to  be  met  can  be  clearly  conveyed  in  a  single 
document.  Sections  1000  through  1999  are  used  to  provide  information 
only,  and  as  such  do  not  respond  to  the  PRD  requirements.  Sections 
2000  through  6999  are  responses  to  specific  PRD  requirements  unless 
designated  support  agency  information  items.  The  UDS  sections  used 
for  information  items  in  a  PSP  are  identified  in  section  1040,  which 
will  serve  as  a  table  of  contents  for  the  document. 

4.2.3  Operations  Directive  ( 0D ) 

The  0D  is  the  support  agency's  response  to  the  OR  and  details  each 
support  function  role,  the  support  equipment,  the  technical  configura¬ 
tion,  and  the  personnel  duties  involved  in  supporting  the  test  or 
operation.  The  0D  may  provide  management  information  or  technical 
requirements  and  guidelines.  It  is  a  listing  of  expected  coverage 
detailing  the  support  posture  of  the  support  agency  for  the  test 
covered  by  the  particular  00.  Requirements  that  cannot  be  met  must  be 
identified.  The  0D  is  normally  prepared  in  sufficient  detail  to 
furnish  instructions  for  a  specific  test  or  test  series. 

The  0D  is  organized  according  to  the  UDS  outline  in  appendix  A  and 
formats  in  volume  3.  The  outline  may  be  further  structured  by  the 
support  agency  to  provide  ready-access  to  information  at  operating 
locations.  The  support  agency  defines  section  structure  as  needed. 

The  major  UDS  section  numbers  and  titles  may  not  be  altered  and 
should,  where  possible,  provide  association  between  a  requirement  and 
the  support  response. 

The  0D  may  be  supplemented  with  standard  operating  procedures  (SOPs), 
extracts,  or  similar  documentation.  The  appropriate  section  in  the  0D 
will  contain  a  reference  to  the  applicable  SOP  and  a  short  statement 
(one  or  two  sentences)  outlining  the  type  of  equipment  and  procedures 
used.  Examples  of  such  standard  procedures  are  radar  and  telemetry 
set-ups. 
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The  OD  must  be  written  in  clear,  concise  technical  language  that  is 
subject  to  one  interpretation  only.  All  abbreviations  must  be  consist¬ 
ent  with  the  abbreviations  used  in  the  OR.  A  common  understanding  of 
such  terms  is  essential.  Other  terms  and  abbreviations  must  not  be 
used  unless  completely  defined  when  first  used  in  each  document.  Not 
more  than  one  abbreviation  will  be  used  to  indicate  the  same  subject, 
nor  must  any  one  abbreviation  be  used  with  more  than  one  meaning. 


CHAPTER  5 


DOCUMENT  PREPARATION  PROCEDURES 


5 . 1  Implementation  Methods 

The  UDS  can  be  implemented  using  either  automated  or  manual  methods. 
While  there  are  some  features  that  are  unique  to  each  method,  gener¬ 
ally  the  documents  and  the  structures  are  the  same  for  both.  The 
difference  is  primarily  the  method  (automated  or  manual)  of  completing 
the  standard  formats  and  preparing  the  documents. 

5.1.1  Manual  Method 

The  manual  techniques  and  format  follow  the  automated  method  very 
closely.  The  format  is  the  same,  using  8  1/2  by  11  inch  paper,  and  is 
shown  in  figures  1  and  2.  The  document  content  is  organized  according 
to  the  outline  given  in  appendix  A .  The  nature  of  the  information 
should  be  that  typically  shown  in  the  formats  contained  in  volumes  2 
and  3  of  this  handbook.  Only  those  formats  applicable  need  to  be 
used.  The  document  then  would  be  typewritten  and  reproduced  according 
to  local  capability  and  regulations.  Close  coordination  between  the 
range  and  range  user  is  essential  during  the  draft  stages  of  the 
documents.  Documents  at  levels  1,  2,  and  3  should  follow  the  guidance 
provided  in  this  handbook.  Unique  to  the  manual  method  is  the  reten¬ 
tion  and  use  of  the  standard  formats  as  blank  forms.  The  formats  in 
volumes  2  and  3  of  this  handbook  are  examples  of  the  formats  to  be 
used  for  the  manual  preparation  of  UDS  documents  and  are  displayed  in 
12  pitch. 

5.1.2  Automated  Method 

The  requirement  for  electronic  transmission  and  processing  of  UDS 
information  has  increased  yearly.  As  a  result,  the  automated  UDS 
system  must  have  flexibility  to  quickly  adapt  to  changing  user 
requirements.  An  8  1/2  by  11  inch  format  was  selected  for  universal 
compatibility.  Primary  considerations  are  to  allow  use  of  electronic 
processing  and  communications  equipment  to  expedite  processing  of  UDS 
documents,  thus  reducing  reproduction  and  distribution  time  for  docu¬ 
ment  transactions  between  users,  and  also  to  allow  easy  access  to 
master  record  storage.  Other  features  of  automation  allow  information 
coding,  electronic  sorting,  and  automatic  data  entry  expansion  capa¬ 
bility.  The  information  content  is  the  same  as  described  in  appendix 
A  and  the  formats  shown  in  volumes  2  and  3.  Graphs,  charts,  and 
photographs  which  are  not  readily  adaptable  to  existing  electronic 
storage  and  transmission  equipment  may  be  handled  separately  as  pro¬ 
vided  in  paragraph  2.7,  Other  Documentation. 

The  basic  form  for  automated  documentation  is  for  requirements  and 
support  commitments  to  be  recorded  in  separate  documents,  for  example, 
a  PRD  and  a  PSP.  An  optional  method  provides  for  combined  support 
requirements  and  commitments.  This  method  generally  is  used  where 
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support  commitments  are  only  a  short  or  abbreviated  response.  How¬ 
ever,  either  the  basic  or  the  optional  method  of  providing  support 
commitments  may  be  expanded  by  the  support  agency  as  necessary  to 
provide  greater  detail.  If  deemed  necessary,  a  fully-worded  reply  may 
be  provided  separately  and  can  contain  an  engineering  plan,  an  engi¬ 
neering  implementation  timetable,  a  funding  plan,  and  a  cost  summary 
in  any  degree  of  detail  desired. 

5 . 2  Page  Format 

The  RCC  Documentation  Group  recognizes  that  documentation  preparation 
resources  vary  at  support  ranges  and  within  the  user  community.  The 
format  described  here  was  developed  to  provide  for  minimum  structure 
and  maximum  flexibility  among  UDS  subscribers.  Within  the  framework 
of  this  basic  format,  support  ranges  and  users  may  develop  UDS 
documentation  to  maximize  preparation,  publication,  and  dissemination. 
A  degree  of  freedom  may  be  used  in  the  preparation  of  documentation; 
however,  the  support  range  will  identify  the  minimal  UDS  documentation 
required  to  process  user  requi rements . 

5.2.1  Classification  Markings 

Space  has  been  provided  at  the  top  and  bottom  of  each  format  page  to 
accommodate  classification  markings.  The  highest  security  classifica¬ 
tion  of  information  appearing  on  a  page  will  be  centrally  placed  at 
the  top  and  bottom  of  the  page.  Computer-generated  classification 
markings  will  be  made  conspicuous  with  a  space  between  each  character 
in  the  word  and  with  a  series  of  three  asterisks  before  and  after  the 
classification.  Unclassified  pages  will  also  be  marked;  however,  no 
spaces  will  appear  between  each  character  in  the  word  unclassified. 

For  example 

*  *  *  UNCLASSIFIED  *  *  * 
***CONFIDENTIAL*** 
***SECRET*** 

Additional  security  markings  will  be  appropriately  placed  by  the 
cognizant  security  authority.  The  documenting  agency  irresponsible 
for  adjusting  the  formats  to  accommodate  necessary  security  classifi¬ 
cation  markings. 

5.2.2  Format  Structure 

The  UDS  page  format  is  72  (10  or  12  pitch)  horizontal  characters  and 
66  vertical  lines  on  a  8  1/2-  by  11-inch  page  (see  figures  1,  2,  and 
3).  The  format  is  subdivided  into  three  elements;  header,  body,  and 
footer.  The  body  of  the  format  page  is  separated  from  the  header 
and  footer  by  a  series  of  72  equal  signs  (=),  called  break  lines. 

Break  lines  permit  easy  access  to  the  information  while  ignoring  the 
header  and  the  footer.  No  line  within  the  body  may  exceed  70  columns 
of  text.  The  71st  column  is  always  blank.  Revised  lines  are  identi¬ 
fied  by  placing  an  R  in  the  72nd  column  (see  figures  1  through  3). 
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To  maximize  full  page  print,  the  format  provides  for  the  sequential 
listing  of  UDS  sections  and  data  descriptions.  The  (JDS  section  titles 
act  as  separators  between  UDS  sections,  while  a  series  of  70  dashes 
(-)  act  as  separators  between  individual  items  within  the  section.  To 
accommodate  the  electronic  exchange  and  processing,  the  standards, 
described  next,  have  been  applied  to  each  of  the  format  elements. 

5.2.2. 1  Header  Standards 

Each  UDS  document  page  shall  contain  a  standard  header  consisting  of 
five  elements  described  below:  classification,  program  title,  docu¬ 
ment  type/number,  revision  number,  and  date. 

CLASSIFICATION:  See  paragraph  5.2.1. 

PROGRAM  TITLE:  Identifies  the  title/name  of  the  program  docu¬ 
ment,  for  example,  WIDGET. 

DOCUMENT  TYPE/NUMBER:  Identifies  the  UDS  document  type 
(PI,  SC,  PRD,  PSP,  OR,  0D)  followed  by  the  assigned  program,  operation, 
or  other  identification  number,  for  example,  PRD/11111. 

REVISION:  Identifies  the  revision  number  of  the  document. 

Original  (unrevised)  documents  carry  the  revision  number  "00."  This 
number  shall  be  incremented  by  1  with  each  published  revision,  for 
example,  01,  02,  03. 

Note :  In  some  automated  systems,  the  date  of  the  revision 

may  be  used  in  lieu  of  the  revision  number.  Revision  may 
also  be  made  to  the  requirement  level  by  dating  the  last 
change  to  the  individual  requirement  (see  figure  3). 

DATE:  Identifies  the  publication  date  of  the  original  document 

or  revision. 

5. 2. 2. 2  Body  Standards 

The  body  of  each  UDS  section  shall  contain  the  appropriate  information 
to  define  program  requirements  or  responses.  In  many  cases,  formats 
and  instructions  have  been  devised  to  prompt  the  author  for  required 
information.  In  those  cases,  all  applicable  questions  shall  be 
answered  either  with  the  appropriate  information  or  other  appropriate 
statement  to  define  the  status  of  the  information,  for  example, 
unknown,  to  be  determined,  to  be  furnished  later,  or  an  appropriate 
cross-reference.  Nonappl i cabl e  prompts  should  be  answered  N/A  or,  if 
the  capability  exists,  the  prompt  itself  may  be  removed.  The  body  of 
every  section  is  divided  into  two  elements:  section  number  and  title, 
and  structured  (SORT)  labels  for  formatted  or  free-form  text. 

The  section  numbers  and  titles  identified  in  the  UDS  Outline  in 
appendix  A  will  be  used  to  identify  the  major  sections  of  UDS  docu¬ 
ments.  Section  numbers  and  titles  shall  start  in  column  1  of  the 
printed  format.  The  use  of  subsections  and  titles  is  left  to  the 
discretion  of  the  documenting  agency.  The  section  number  and  title, 
for  example,  1000  -  Administrative,  must  be  entered  as  a  major 
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heading.  The  section  number  and  title  precede  the  subsection  numbers 
and  titles  whether  or  not  general  information  is  included.  Structured 
(SORT)  labels  and  text  provide  for  the  electronic  sorting  and  retrieval 
of  data  from  an  electronic  data  base.  Disciplined  compliance  to  data 
structure  is  mandatory  in  automated  systems  to  facilitate  the  transfer 
of  documents  between  data  bases  and  for  the  retrieval  of  data  base 
information. 

Additional  structured  (NON-SORT)  labels  are  specifically  identified  on 
applicable  formats.  When  used,  structured  labels  for  all  documents 
shall  start  in  column  1  of  the  printed  format.  When  necessary  to 
continue  the  data  following  a  structured  label,  that  data  will  begin 
in  column  2.  Free-form  text  data  will  begin  in  column  2.  Some  elec¬ 
tronic  UOS  systems  may  require  that  text  start  in  other  than  column  2. 
In  those  cases,  the  local  system  data  base  manager  will  provide  the 
necessary  supplemental  information  to  users  of  those  systems  (see 
figure  3  ) . 

Note :  The  labels  need  only  be  used  if  applicable.  To  be 

determined  (TBD)  will  be  entered  following  the  label  when  data 
is  applicable  but  not  available.  Nonappl i cabl e  labels  will 
be  followed  by  N/A  for  manual  systems  only. 

The  following  labeled  standards  and  descriptions  are  shown  next: 

ITEM  NO.  : 

REQUESTER: 

SUPPLIER: 

TEST  CODE: 

LOCATION:  (Support  Formats  Only) 

INFORMATION  : 

REQUIREMENTS(  )  INFORMATION!  ): 

REQUIREMENTS  : 

RESP0NSE(  )  I NFORMAT 1 0  N (  ): 

RESPONSE  : 

ITEM  NO.:  A  sequential  number,  beginning  at  01,  identifying  the 
item  listed  under  each  UDS  section.  This  label  is  used  for  each 
requirement,  response,  or  informational  item  documented.  The  item 
number  used  for  responses  to  requirements  is  the  same  as  that  of  the 
correspond i ng  item  number  appearing  in  the  document.  The  corres¬ 
ponding  document  section  number  is  listed  for  clarification.  In 
addition,  if  there  are  supplemental  support  agency  generated  informa¬ 
tion  items,  explain  the  items  on  UDS  Format  1063  -  Special  Code  Defi¬ 
nition.  Other  item-related  information  may  be  entered  under  this 
label  as  shown  in  figure  3. 

REQUESTER:  A  code,  identified  on  UDS  Format  1063  -  Special 

Code  Definition,  assigned  to  the  requester  of  a  requirement.  Sub¬ 
requesters,  similarly  identified,  will  be  indicated  by  the  use  of  a 
slash  (/)  immediately  following  the  requester  code;  for  example, 

T/DE22  might  indicate  a  requirement  established  by  the  NASA  Johnson 
Space  Center/Flight  Requirements  Office.  Each  requester/ subrequester 
shall  be  separated  by  a  space.  It  is  recommended  that,  when  possible. 
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either  the  assigned  agency  alphabetical  code  or  the  agency  acronym  as 
shown  in  appendix  8  be  used  as  standard  requester  codes. 

SUPPLIER:  A  code,  identified  on  UDS  Format  1063  -  Special  Code 

Definition,  assigned  to  the  organization  providing  support.  Sub¬ 
suppliers  are  similarly  identified  by  the  use  of  a  slash  (/)  immedi¬ 
ately  following  the  supplier  code.  For  example,  W/SAC  might  indicate 
a  response  provided  by  the  Western  Test  Range  concerning  a  commitment 
by  the  host  SAC  base.  It  is  recommended  that,  when  possible,  either 
the  assigned  agency  alphabetical  code  or  the  agency  acronym  as  shown 
in  appendix  B  be  used  as  standard  supplier/subsupplier  codes. 

TEST  CODE:  A  code,  identified  on  UDS  Format  1062  -  Test  Code 
Definition,  assigned  to  a  specific  test  requirement,  response,  or 
information  item  which  identifies  the  various  test  activities.  These 
test  codes  are  used  as  a  method  of  correlating  support  requ i r emen ts . 
Any  support  requirement  referenced  to  a  test  code  indicates  that  this 
support  will  be  required  during  particular  test  program  activity. 

LOCATION:  The  location  where  the  support  is  to  be  provided. 

REQUIREMENT:  A  description  of  the  user  agency  support  require¬ 

ment. 

RESPONSE:  A  description  of  the  support  agency  response  to  a  user 

requi rement. 

Note :  Some  electronic  UDS  systems  may  require  that 

additional  commitment/response  information  be  developed 

(see  figure  3). 

INFORMATION:  A  description  of  user  or  support  agency  data  sub¬ 

mitted  for  informational  purposes  only.  Information  shall  not  be 
construed  as  a  requirement  nor  as  a  response  to  a  requirement. 

Additional  structured  data  may  be  required  to  satisfy  the  requirements 
of  electronic  UDS  systems.  Data  base  managers  of  these  systems  are 
responsible  for  providing  any  specialized  formatting  instructions  to 
their  subscribers  (see  figures  1,  2,  and  3). 

5. 2. 2. 3  Footer  Standards 

Each  UDS  document  page  shall  contain  a  standard  footer  consisting  of 
the  following  elements: 

Page  Number.  Identifies  the  sequential  page  number  within  a 
document  starting  with  1  at  the  first  page  of  the  document.  Where  a 
document  contains  a  series  of  tests,  each  test  may  be  numbered  using 
the  test  number  followed  by  a  sequential  number  starting  with  1  on  the 
first  page  of  the  test.  Pages  added  to  the  beginning  of  a  manually 
prepared  document  or  imbedded  text,  as  the  result  of  a  revision,  will 
be  identified  by  the  page  number  0  followed  by  a  sequential  series  of 
decimal  numbers  beginning  at  .1  for  each  page  added.  For  example,  two 
pages  added  at  the  beginning  of  a  document  will  be  numbered  0.1  and 
0.2.  Pages  added  between  two  sequentially  numbered  pages,  as  the 
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result  of  a  revision,  will  be  identified  by  the  addition  of  a  decimal 
following  the  page  number  of  the  preceding  page,  followed  by  a  sequen¬ 
tial  series  of  numbers  beginning  at  1  for  each  page  added.  For  exam¬ 
ple,  three  pages  added  by  revision  and  situated  between  pages  25  and 
26  will  be  numbered  25.1,  25.2,  and  25.3.  Pages  added  at  the  end  of  a 
document,  as  the  result  of  a  revision,  will  take  on  the  next  sequen¬ 
tial  page  number  following  the  last  page. 

Classification.  (See  paragraph  5.2.1.) 

Format  Number  and  Format  Approval  Date .  Used  for  UDS  document 
control  purposes  only,  and  not  required  to  be  shown  (see  paragraph 
2.10.2). 
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u 

H3 

H4 

H5 

H6 


B2 
B  3 
B4 
B5 
B6 
B7 
B8 
B9 
BIO 
Bll 
812 
B 1 3 
B14 
B 15 
B 1 6 
B 1  7 
B 18 
B 1 9 
B20 
B21 
822 
B23 
B24 
B25 
B26 
B27 
B28 
B29 
B30 
B31 
B32 
B33 
B34 
B35 
B36 
B37 
B38 
B39 
B40 
B41 

B42 
B43 
B44 
B45 
B46 
B47 
B48 
B49 
B50 
B  5  1 
B52 
B53 
FI 
F  2 
F3 
F  4 
F  5 
F  6 


.  10 . 20 . 30 . 40 . 50 . 60 . 70. 

CLASSIFICATION:  *  *  *  UNCLASSIFIED  *  *  * 

PROGRAM  TITLE:  WIDGET 

OOC  TYPE/NO  . :  PRD/11111  REVISION:  DATE:  03  MAR  86 

SECTION  NUMBER’:~SECTION"TITLE  (EXAMPLE  li 

ITEM  NO . :  01 

INFORMATION:  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 
TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  2) 

ITEM  NO.:  01 
REQUESTER:  T/DE22 
TEST  CODE:  01  02  03  04 

REQUIREMENT  X)  I NFORMAT I  ON (  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 
TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  3) 

ITEM  NO. :  01 

SUPPLIIER:  W/SAC 
TEST  CODE:  01  02  03  04 

RESPONSE ( X)  I NFORMATION (  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 
TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 


SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  4) 

ITEM  NO. :  01 

REQUESTER:  T/DE22 
SUPPLIER:  W/SAC 
TEST  CODE:  01  02  03  04 

REQUIREMENT! X)  INFORMATION!  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 
TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 
RESPONSE ( X )  I NFORMATION (  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


NOTE  1:  The  examples  above  represent  a  typical  expression  of 

requirements,  responses,  and  informational  data  in  the  UDS 
using  the  manual  or  word-processi ng  assisted  methods  of 
preparing  unclassified  documents. 

EXAMPLE  1  =  TYPICAL  INFORMATIONAL  ITEM 
EXAMPLE  2  =  TYPICAL  REQUIREMENT  ITEM 
EXAMPLE  3  =  TYPICAL  RESPONSE  ITEM 

EXAMPLE  4  =  TYPICAL  REQUIREMENT/RESPONSE  ITEM  (COMBINED) 

NOTE  2:  Numbers  10-70,  H1-H7,  B1-B53,  and  F1-F6  are  for  inform at ional 
purposes  and  are  not  part  of  the  format  and  are  not  printed. 

H  =  header,  B  =  body  and  F  =  footer. 


NOTE  3:  THIS  EXAMPLE  FORMAT  IS  NOT  TO  SCALE. 


CLASSIFICATION:  *  *  *  UNCLASSIFIED  *  *  *  UDS  GEN  R 

JAN  89 

Figure  1.  Example  -  manual/word  processing  format  (unclassified). 
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HI 

H2 

H3 

H4 


H  7 
B 1 
B2 
B  3 
B4 
B  5 
B6 
B  7 
B8 
B9 
BIO 
B  1 1 
B 1  2 
B 1 3 
B  1 4 


B 1 5 
B 1 6 
B  1 7 


B 1 8 
B  1 9 
B20 
B21 
B22 
B23 
B24 
B25 
B  26 


830 
B  3  1 
B32 
B  3  3 
B34 
B  3  5 
B  3  6 
B  3  7 
B  38 
B39 
B40 
B41 


B42 

B43 

B44 

B45 

B46 

B47 

B48 

B49 


B  50 
B51 
B52 
853 
FI 
F  2 
F  3 
F  4 
F  5 
F  6 


.  10 . 20 . 30 . 40 . 50 . 60 . 70. 

(U)  CLASSIFICATION:  *  *  *  CLASSIFIED  *  *  * 

(U)  PROGRAM  TITLE:  WIDGET 

(U)  DOC  TYPE/NO.:  PRD/11111  REVISION:  00  DATE:  03  MAR  86 

(U)  SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  1) 

(U  )  ITEM  NO . :  01 

(U)  INFORMATION:  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 

(U)  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


(U)  SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  2) 

(U)  ITEM  NO. :  01 

(U)  REQUESTER:  T/DE22 

(U)  TEST  CODE:  01  02  03  04 

(U)  REQUIREMENT(X)  INFORMATION*  j:  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 
(U)  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


(U)  SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  3) 

(U)  ITEM  NO. :  01 

(U)  SUPPLIIER:  W/SAC 

(U)  TEST  CODE:  01  02  03  04 

(U)  RESPONSE* X)  INFORMATION*  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 

(U)  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 


(U)  SECTION  NUMBER  -  SECTION  TITLE  (EXAMPLE  4) 

(U)  ITEM  NO. :  01 

(U)  REQUESTER:  T/DE22 

(U)  SUPPLIER:  W/SAC 

(U)  TEST  CODE:  01  02  03  04 

(U)  REQU I REMENT  (  X )  INFORMATION*  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  R 
(U)  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 
(U)  RESPONSE ( X )  INFORMATION*  ):  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT  TEXT 


(U)  NOTE  1: 
(U) 

(U) 

(U) 


The  examples  above  represent  a  typical  expression  of 
requirements,  responses,  and  informational  data  in  the  UDS 
using  the  manual  or  wor d-p r oces s i ng  assisted  methods  of 
preparing  classified  documents. 


(U) 
*  U ) 
(U) 
(U) 


EXAMPLE  1  =  TYPICAL  INFORMATIONAL  ITEM 
EXAMPLE  2  =  TYPICAL  REQUIREMENT  ITEM 
EXAMPLE  3  =  TYPICAL  RESPONSE  ITEM 

EXAMPLE  4  =  TYPICAL  R EQU I REMENT/ RE SPON SE  ITEM  (COMBINED) 


(U)  NOTE  2: 


THIS  EXAMPLE  FORMAT  IS  NOT  TO  SCALE. 


(U) 


CLASSIFICATION:  *  *  *  CLASSIFIED  *  *  *  UDS  GEN  R 

JAN  89 

Figure  2.  Example  -  manual/word  processing  format  (classified). 
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HI 
H* 
H  3 
H4 
H  5 
H  6 
H  7 
B 1 
B2 
B3 
B4 
B5 


B6 
B  7 
B8 
B9 
BIO 
B  1 1 
B 1 2 
B  1 3 
B  1 4 
B 1  5 
B 1 6 
B  1  7 
81 
B  1 9 
B20 
B21 
B22 
B23 
B24 
B25 
B26 
B27 
B28 
B  29 
B30 
B31 
B32 
B33 
634 
B35 
B36 
B37 
B  38 
B39 
B40 
B41 
B42 
B43 
B44 
B45 
B46 
B47 
B48 
B49 
B50 
B  5  1 
B  5  2 
B53 
FI 
F  2 
F  3 
F  4 
F  5 
F  6 


.  10 . 20 . 30 . 40 . 50 . 60 . 70. 

CLASSIFICATION:  *  *  *  UNCLASSIFIED  *  *  * 

PROGRAM  TITLE:  WIDGET 

DOC  TYPE/NO.:  PRD/11111  REVISION:  03/12/86  DATE:  03  MAR  8^ 

2805  -  OTHER  COMMUNICATIONS  -  TELEVISION 

ITEM  NO.:  AAAA  BBBB  CCCC  DODD  EEEE  FFFFFFFF  G 
REQUESTER:  HHHHHHHHHHHH  HHHHHHHHHHHHH  HHHHHHHHHHHH 

SUPPLIER:  IIIIIIIIIIII  IIIIIIIIIIII  IIIIIIIIIIII 

TEST  CODE:  JJJJJJ  JJJJJJ  JJJJJJ  JJJJJJ  JJJJJJ  JJJJJJ  JJJJJJ 
TYPE  EQUIPMENT:  KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
SUBJECT  TO  BE  REVIEWED:  KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
LOCATION  :  KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
PERIOD :  KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

PURPOSE/ RE  MARKS:  KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK  R 
RESPONSE:  LLLLLLLLLL  MMMMMM  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN  R 


NOTE  1:  This  example  represents  an  automated  UDS  system  format  where 
each  requirement  and  its  response  reside  together  in  the 
database.  While  the  system  maintains  the  basic  UDS  integrity 
data  structure  is  strictly  defined  for  electronic  processing. 

The  following  codes  are  used  in  the  example  above: 

A  -  SEQUENTIAL  ITEM  NUMBER 
B  -  UDS  FORMAT  NUMBER  * 

C  -  DATA  BASE  IDENTIFICATION  CODE  * 

D  -  UDS  SECTION  NUMBER  * 

E  -  REQUIREMENT  APPROVAL  STATUS  * 

F  -  REQUIREMENT  APPROVAL  DATE  * 

G  -  REQUIREMENT  SECURITY  CLASSIFICATION  * 

H  -  REQUESTER/SUB-REQUESTER  CODES 
I  -  SUPPLIER/SUB-SUPPLIER  CODES 
J  -  TEST  CODES 
K  -  REQUIREMENT/TEXT 
L  -  SUPPORT  AGENCY 
M  -  COMMITMENT  DATE 
N  -  RESPONSE  TEXT 
R  -  REVISION  SYMBOL 

NOTE  2:  This  format  is  a  structured  automated  version  corresponding 
to  UDS  Section  2805. 


NOTE  3:  Data  structures  on  automated  systems  vary  due  to  hardware/ 
software  limitations,  therefore,  a  universal  format  for  all 
systems  is  not  yet  defined.  For  this  reason,  format  usage  is 
left  flexible  for  the  developer  of  the  system.  Any  special 
codes  developed  will  be  explained  in  UDS  Section  1603  - 
Special  Code  Definition. 

NOTE  4;  THIS  EXAMPLE  FORMAT  IS  NOT  TO  SCALE. 

*  Examples  of  I  tern  No.  supplemental  information. 


CLASSIFICATION:  *  *  *  UNCLASSIFIED  *  *  *  UDS  GEN  9^ 

JAN  89 

Figure  3.  Example  -  an  automated  system  format  (structured). 
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APPENDIX  A 
UOS  OUTLINE 


A-  1 


APPENDIX  A 


UDS  OUTLINE 


DOCUMENT  CODE:  PI  =  PROGRAM  INTRODUCTION 

SC  =  STATEMENT  OF  CAPABILITY 
R  =  PROGRAM  REQUIREMENTS  DOCUMENT/OPERATION 
REQUIREMENTS 

S  =  PROGRAM  SUPPORT  PLAN/OPERATIONS  DIRECTIVE 


DOCUMENT 


SECTION  AND  TITLE 


PROGRAM  ADMINISTRATIVE  AND  TECHNICAL  INFORMATION  -  SECTION  1000 
TO  1999 

ADMINISTRATIVE 


PI  SC  R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 
R  S 


1000  -  Administrative 
1010  -  Approval  Authority 
1020  -  Distribution  List 

1030  -  Revision  Approval 

1031  -  Revision  Control  and  Classification 
1040  -  Index  of  UDS  Sections  Used 

1050  -  Program/Mission  Security  Information 
1052  -  System  Security  Classification 
1054  -  System  Security  Classification  Matrix 
1056  -  Security  Authorization 

1060  -  Preface 

1061  -  Special  Abbreviations  and  Nomenclature 

1062  -  Test  Code  Definition 

1063  -  Special  Code  Definition 

1064  -  Key  Technical  Personnel 

1065  -  Technical  References 


PROGRAM/MISSION  INFORMATION 


PI  SC  R  S  1100 
R  S  1110 
R  1120 
R  1125 
R  1130 
R  ‘1131 
R  S  1140 


Prograra/Mission  Information  -  Program  Description 

Experiments  Description 

System  Mission  Capabilities 

System  Functional  Description 

Mission/Test  Description 

Mission/Test  Objectives 

Test  Program  Operations  Schedule 


SYSTEM  INFORMATION  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 


PI  SC  R 
R 
R 
R 
R 
R 
R 

R 

R 

R 

R 

R 

R 


1300  -  System  Information 

1310  -  Vehicle/Test  Item  Description 

1311  -  Vehicle/Test  Item  Characteristics 

1312  -  Vehicle/Test  Item  Drawings 

1313  -  Vehicle/Test  Item  Ordnance  Items  Description 

1314  -  Vehicle/Test  Item  Ordnance  Items  Drawing 

1315  -  Vehicle/Test  Item  Flame  Plasma  Model  of  the  Exhaust 

Plume 

1320  -  Spacecraft/Payload  Description 

1321  -  Spacecraft/Payload  Characteristics 

1322  -  Spacecraft/Payload  Drawings 

1323  -  Spacecraft/Payload  Ordnance  Items  Description 

1324  -  Spacecraft/Payload  Ordnance  Items  Drawing 

1325  -  Spacecraft/Payload  Flame  Plasma  Model  of  the  Exhaust 

Plume 


INSTRUMENTATION  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 

PI  SC  R  1400  -  Instrumentation  Systems 

R  S  1405  -  Frequency  Utilization  Summary 

METRIC  TRACKING  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 

R  1410  -  Metric  Tracking  Systems  Operating  Description 

R  1411  -  Metric  Tracking  Systems  Transponder  Characteristics 

R  1412  -  Metric  Tracking  Systems  Antenna  Systems 

R  1413  -  Metric  Tracking  Systems  Diagrams 

TELEMETRY  SYSTEMS  -  VEHICLE/TEST  ITEM/ SPACECRAFT/ PAYLOAD 


R 

R 

R 

R 

R 

R 

R 


1420  -  Telemetry  Systems  Operating  Description 

1421  -  Telemetry  Systems  Characteristics 

1422  -  Telemetry  Systems  Antenna  Systems 

1423  -  Telemetry  Systems  Diagrams 

1424  -  Telemetry  Systems  Analog  Channel  Description 

1425  -  Telemetry  Systems  Digital  Format 

1426  -  Telemetry  Systems  Data  Recorder  Characteristics 


COMMAND  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 

R  1430  -  Command  Systems  Operating  Description 

R  1431  -  Command  Systems  Characteristics 

R  1432  -  Command  Systems  Antenna  Systems 

R  1433  -  Command  Systems  Diagrams 

VOICE  COMMUNICATIONS  SYSTEMS  -  VEHICLE/TEST  ITEM/ 
SPACECRAFT/PAYLOAD 

R  1440  -  Voice  Communications  Systems  Operating  Description 

R  1441  -  Voice  Communications  Systems  Characteristics 


A- 3 


R  1442  -  Voice  Communications  Systems  Antenna  Systems 

R  1443  -  Voice  Communications  Systems  Diagrams 

COMPOSITE  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 


R 

R 

R 

R 

R 

R 

R 

R 


1450  -  Composite  Systems  Operating  Description 

1451  -  Composite  Systems  Characteristics 

1452  -  Composite  Systems  Received  Data  Characteristics 

1453  -  Composite  Systems  Transmitted  Data  Characteristics 

1454  -  Composite  Systems  Antenna  Systems 

1455  -  Composite  Systems  Diagrams 

1456  -  Composite  Systems  Operating  Modes 

1457  -  Composite  Systems  Data  Recorder  Characteristics 


TELEVISION  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 


R 

R 

R 

R 

R 

R 

R 

R 


1460  -  Vehicle/Test  Item  Television  Systems  Operating 

Description 

1461  -  Vehicle/Test  Item  Television  Systems 

Characteristics 

1462  -  Vehicle/Test  Item  Television  Systems  Antenna 

Systems 

1463  -  Vehicle/Test  Item  Television  Systems  Format 

Description 

1465  -  Spacecraft/Payload  Television  Systems  Operating 

Description 

1466  -  Spacecraft/Payload  Television  Systems  Characteristics 

1467  -  Spacecraft/Payload  Television  Systems  Antenna  Systems 

1468  -  Spacecraft/Payload  Television  Systems  Format 

Descript  ion 


OTHER  SYSTEMS  -  VEHICLE/TEST  ITEM/SPACECRAFT/PAYLOAD 


R 

R 


PI  SC  R 
R 


PI  SC  R 
R 
R 
R 


PI  SC  R 
R 
R 
R 


1470  -  Recovery  Location  Aids 
1480  -  Other  Systems 

REQUESTING  AGENCY'S  SUPPORT  INSTRUMENTATION/EQUIPMENT 

1500  -  Requesting  Agency's  Support  Instrumentation/Equipment 
1510  -  Characteristics 

SYSTEMS  READINESS/PRELAUNCH  TESTS 

1600  -  Systems  Readiness/Prelaunch  Tests 

1610  -  Readiness/Pre  launch  Tests  Identification 

1620  -  Readiness/Prelaunch  Tests  Sequence 

1630  -  Readiness/Pre  launch  Tests  Terminal  Countdown 

TEST  ENVELOPE  INFORMATION 

1700  -  Test  Envelope  Information 

1710  -  Major  Mission  Events  -  Launch  Phase 

1711  -  Major  Mission  Events  -  Flight 

1712  -  Space  Maneuver  -  Application  of  Thrust 


A-4 


TRAJECTORY  INFORMATION 


R  1720  -  Trajectory  Plan  Views 
R  1721  -  Trajectory  Profile  Views 
R  1722  -  Launch  Trajectory 
R  1723  -  Orbital  and  Space  Trajectory 
R  1724  -  Terminal  Trajectory 

OPERATIONAL  HAZARDS 

PI  SC  R  S  1800  -  Operational  Hazards 

R  1810  -  Operational  Hazards  Reports 

TEST/MISSION  OPERATIONAL  REQUIREMENTS  -  SECTIONS  2000  TO  6999 
TEST  OPERATIONAL  CONCEPTS/SUMMARIES 

PI  SC  R  S  2000  -  Test  Operational  Concepts/Summaries 

R  S  2010  -  Ground  Support  Instrumentation  Summary 
S  2020  -  Support  Plan  Summary 
S  2030  -  Support  Commitments 
S  2040  -  Funding  Information 
S  2050  -  Implementation  Schedule 
S  2051  -  Personnel  Assignment  Schedule 
S  2060  -  Support  Requirements  Which  Cannot  Be  Met 
S  2070  -  Engineering  Plan 
S  2071  -  Engineering  Plan  -  Alternate 
S  2080  -  Requester's  Responsibilities 
S  2098  -  Flight  Safety  Operational  Concepts 
S  2099  -  Range  Derived  Requirements 

METRIC  MEASUREMENT  AND  DATA 

PI  SC  R  S  2100  -  Metric  Data 

R  S  2110  -  Metric  Data  -  Launch 

R  S  2111  -  Metric  Data  -  Midcourse 

R  S  2112  -  Metric  Data  -  Orbital  and  Space 

R  S  2114  -  Metric  Data  -  Terminal 

R  S  2115  -  Metric  Data  -  Signature 

R  S  2116  -  Metric  Data  -  Other 

S  2117  -  Metric  Data  Accuracies 
R  S  2120  -  Metric  Data  Parameter  Recordings 

R  S  2130  -  Metric  Data  Network  Coverage 

R  S  2160  -  Metric  Data  Coverage 

R  S  2170  -  Metric  Data  -  Engineering  Sequential 


TELEMETRY  MEASUREMENT  AND  DATA 

PI  SC  R  S  2200  -  Telemetry  Data 

R  S  2210  -  Telemetry  Recording  Interval 

R  S  2220  -  Telemetry  Analog  Strip  Chart  Recording  Format 

R  S  2230  -  Telemetry  Event  Recording  Format 

R  S  2240  -  Telemetry  Decommutation  Processing  Specifications 

R  S  2260  -  Telemetry  Coverage 

COMMAND  C0NTR0L/DESTRUCT 

PI  SC  R  S  2300  -  Command  Control/Destruct 

R  S  2310  -  Command  Control 

R  S  2320  -  Command  Destruct 

R  S  2330  -  Command  Up-Data  Link 

R  S  2340  -  Command  Up-Data  Link  Recordings 

R  S  2360  -  Command  Up-Data  Link  Stations  Coverage 

AIR/GROUND  VOICE  COMMUNICATIONS 

PI  SC  R  S  2400  -  Air/Ground  Voice  Communications 

R  S  2410  -  Air/Ground  Voice  Communications  Recordings 

R  S  2460  -  Air/Ground  Voice  Communications  Coverage 

COMPOSITE  SYSTEMS 

PI  SC  R  S  2500  -  Composite  Systems 

R  S  2510  -  Composite  Systems  -  Detail 

R  S  2520  -  Composite  Systems  -  Parameter  Recordings 

R  S  2530  -  Composite  Systems  -  Event  Recording  Format 

R  S  2540  -  Composite  Systems  -  Analog  Strip  Chart  Recording 

Format 

R  S  2560  -  Composite  Systems  Coverage 

OTHER  SYSTEMS 

PI  SC  R  S  2600  -  Other  Systems 

R  S  2601  -  Other  Systems  -  Directed  Energy 

R  S  2605  -  Other  Systems  -  Support  Instrumentation 

R  S  2606  -  Other  Systems  -  Environmental 

R  S  2610  -  Ot'  er  Systems  -  Data 

R  S  2660  -  Other  Systems  Coverage 

GROUND  COMMUNICATIONS 

PI  SC  R  S  2700  -  Ground  Communications 

R  S  2710  -  Ground  Communications  Detail 

R  S  2720  -  Ground  Communications  Network  Drawings 

R  S  2730  -  Ground  Communications  Network  Transmission  -  Voice 

R  S  2731  -  Ground  Communications  Network  Transmission  -  Secure 

Voice 

R  S  2733  -  Ground  Communications  Network  Transmission  -  Teletype 

R  S  2735  -  Ground  Communications  Network  Transmission  -  Secure 

Data 
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R  S  2736  -  Ground  Communications  Network  Transmission  - 
Television/Data 

R  S  2737  -  Ground  Communications  Network  Transmission  - 
Facs imi le 

R  S  2740  -  Ground  Communications  -  Intercommunications  Systems 
R  S  2760  -  Ground  Communications  Terminations  ■  Voice 

R  S  2761  -  Ground  Communications  Terminations  -  Secure  Voice 

R  S  2762  -  Ground  Communications  Terminations  -  Point-to-Point 

R  S  2763  -  Ground  Communications  Terminations  -  Teletype 

R  S  2765  -  Ground  Communications  Terminations  -  Secure  Data 

R  S  2766  -  Ground  Communications  Terminations  -  Television/Data 

R  S  2768  -  Ground  Communications  Terminations  -  Voice  Radio 

R  S  2769  -  Ground  Communications  Terminations  -  Miscellaneous 

R  S  2770  -  Ground  Communications  Recordings 

R  S  2780  -  Ground  Communications  -  Telephone 

OTHER  COMMUNICATIONS 

PI  SC  R  S  2800  -  Other  Communications 

R  S  2805  -  Other  Communications  -  Television 

R  S  2810  -  Other  Communications  -  Timing 

R  S  2820  -  Other  Communications  Sequencer 

R  S  2830  -  Other  Communications  -  Visual  Countdown  and  Status 

Indicators 


REALTIME  DATA  DISPLAY/CONTROL 

PI  SC  R  S  3000  -  Realtime  Data  Display/Control 

R  S  3010  -  Realtime  Flight  Control/Support  Centers 

R  S  3020  -  Realtime  Flight  Control  Data  Acquisition 

R  S  3030  -  Realtime  Displays  and  Consoles 

R  S  3031  -  Realtime  Displays 

R  S  3032  -  Realtime  Console  Command  Panels 

R  S  3033  -  Realtime  Console  Analog  Recorders 

R  S  3034  -  Realtime  Console  Drawings 

S  3035  -  Realtime  Console  Module  Description 

S  3036  -  Realtime  -  Summary  of  Console  Locations 

S  3037  -  Realtime  -  Summary  of  Console  Module  Locations 

S  3038  -  Realtime  Data  Displays  and  Consoles  -  Functional 
Block  Diagram 

S  .3039  -  Realtime  -  Other  Group  Displays  and  Controls 
R  S  3040  -  Realtime  Data  Formats 
R  S  3041  -  Realtime  Tracking  Data  Format  Control 
R  S  3042  -  Realtime  Telemetry  Data  Format  Control 

R  S  3043  -  Realtime  Telemetry  Data  Formats 

R  S  3Q44  -  Realtime  Command  Data  Format  Control 

R  S  3045  -  Realtime  Remote  Site  Data  Processing 

R  S  3050  -  Realtime  Data  Testing 

R  S  3060  -  Realtime  Data  Interfaces 

R  S  3061  -  Realtime  Data  Interface  Criteria 

R  S  3062  -  Realtime  Data  Interface  Criteria  Drawings 

R  S  3070  -  Realtime  Data  Computer 

R  S  3080  -  Realtime  Data  Distribution 
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PHOTOGRAPHIC 


PI  SC  R  S  3100  -  Photographic 

R  S  3110  -  Photographic  -  Documentary 
R  S  3120  -  Photographic  -  Engineering 

METEOROLOGICAL 

PI  SC  R  S  3200  -  Meteorological 

R  S  3210  -  Meteorological  -  Minima 

R  S  3220  -  Meteorological  -  Forecasts 

R  S  3230  -  Meteorological  -  Observations 

R  S  3240  -  Meteorological  -  Instrumentation  Location  Diagram 

R  S  3250  -  Meteorological  -  Space  Environment 

R  S  3260  -  Meteorological  -  Consultant  Services 

RECOVERY 

PI  SC  R  S  3300  -  Recovery 

R  S  3310  -  Recovery  -  Ships  and  Aircraft  Coverage 
R  S  3320  -  Recovery  -  Items  To  Be  Recovered 
R  S  3330  -  Recovery  -  Salvage  and  Disposition 
R  S  3340  -  Recovery  -  Planned  Areas 
R  S  3350  -  Recovery  -  Contingency  Areas 
R  S  3360  -  Recovery  -  Abort  Areas 

OTHER  TECHNICAL  SUPPORT 

PI  SC  R  S  3400  -  Other  Technical  Support 

R  S  3410  -  Other  Technical  Support  -  Aircraft 
R  S  3411  -  Other  Technical  Support  -  Seacraft 
R  S  3420  -  Other  Technical  Support  -  Targets 
R  S  3430  -  Summary  of  Frequency  Protection 
R  S  3431  -  Emitting  Systems  Protection 
R  S  3440  -  Geodetic  and  Gravitational  Data 
R  S  3450  -  Other  Technical  Support  -  Training 

MEDICAL 

PI  SC  R  S  3500  -  Medical 

R  S  . 3505  -  Medical  -  Bio-Science 
R  S  3510  -  Medical  -  Personnel  -  Active 
R  S  3520  -  Medical  -  Personnel  -  Standby 
R  S  3530  -  Medical  -  Faci lity .Equipment .Services 

PUBLIC  AFFAIRS  SERVICES 


PI  SC  R  S  3600 
R  S  3610 
R  S  3620 


Public  Affairs  Services 

Public  Affairs  Services  -  Personnel  Assignments 
Public  Affairs  Services  -  News  Media  Personnel 
Posit  ions 
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DATA  COORDINATE  SYSTEMS 

PI  SC  R  S  4000  -  Data  Coordinate  Systems  Description 

DATA  PROCESSING 

PI  SC  R  S  4100  -  Data  Computer  Processing  Specifications 

R  S  4110  -  Data  Computer  Processing  Specifications  -  Detail 
R  S  4160  -  Data  Processing  -  Other 

DATA  DISPOSITION 

PI  SC  R  S  4200  -  Data  Disposition 

S  4201  -  Data  Disposition  -  Data  Availability 
R  S  4205  -  Data  Disposition  -  Reports 

R  S  4210  -  Data  Disposition  -  Detail  -  Metric  Tracking 

R  S  4211  -  Data  Disposition  -  Detail  -  Telemetry 

R  S  4214  -  Data  Disposition  -  Environmental 
R  S  4215  -  Data  Disposition  -  Detail  -  Voice/TV  Recording 

R  S  4216  -  Data  Disposition  -  Detail  -  Photographic 

R  S  4217  -  Data  Disposition  -  Detail  -  Meteorological 

R  S  4218  -  Data  Disposition  -  Detail  -  Computer  Processing 

R  S  4219  -  Data  Disposition  -  Detail  -  Miscellaneous 

BASE  FACILITIES/LOGISTICS 

PI  SC  R  S  5000  -  Base  Facilities/Logistics 

PERSONNEL  ASSIGNMENT  SCHEDULES 

PI  SC  R  S  5100  -  Personnel  Assignment  Schedules 

R  S  5110  -  Personnel  Assignment  Schedules  -  Detail 

R  S  5120  -  Personnel  Assignment  Schedules  -  Housing 

TRANSPORTATION 

PI  SC  R  S  5200  -  Transportation 

R  S  5210  -  Transportation  -  Surface  Logistics  Schedule 

R  S  5220  -  Transportation  -  Air  Logistics  Schedule 

SERVICES 

PI  SC  R  S  5300  -  Services 

R  S  5301  -  Services  -  Administrative,  Personnel,  and  Office 
R  S  5302  -  Services  -  Fire  and  Rescue 

R  S  5303  -  Services  -  Security  and  Safety 

R  S  5304  -  Services  -  Community,  Education  and  Food  Service 

R  S  5305  -  Services  -  Utilities  (Electrical,  Water,  and 

Sanitat ion) 

R  S  5306  -  Services  -  Procurement,  Shipping,  Receiving,  and 
Stock  Control 

R  S  5307  -  Services  -  Handling,  Storage,  and  Disposal 

R  S  5308  -  Services  -  Air  Conditioning  and  Environmental 

Observat ions 
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R  S  5309  -  Services  -  Physical  and/or  Life  Science  Experiments 

R  S  5310  -  Services  -  Propellants,  Gases,  and  Chemicals 

R  S  5320  -  Services  -  Fuels  and  Lubricants 

R  S  5330  -  Services  -  Miscellaneous  Lubricants,  Hydraulic 

Fluids,  Preservatives,  Etc. 

R  S  5340  -  Services  -  Vehicles  and  Land  Transportation 

R  S  5341  -  Services  -  Ground  Handling  Equipment 

R  S  5350  -  Services  -  Requesting  Agency  Aircraft 

R  S  5351  -  Services  -  Air  Operations 

R  S  5360  -  Services  -  Seacraft 

R  S  5361  -  Services  -  Marine  Operations 

R  S  5370  -  Services  -  Chemical  Cleaning 

R  S  5380  -  Services  -  Purchase  of  Equipment  or  Supplies 

LABORATORY 


PI  SC  R  S 
R  S 
R  S 
R  S 


5400  -  Laboratory 

5405  -  Laboratory  -  Technical  Shops  and  Labs 
5410  -  Laboratory  -  Chemical  and  Physical  Analysis 
5420  -  Laboratory  -  Special  Environment 


MAINTENANCE 


PI  SC  R  S  5500 
R  S  5510 


Maintenance 

Maintenance  -  Buildings  and  Grounds 


FACILITIES 


PI  SC  R  S  5600  -  Facilities 

R  S  5610  -  Facilities  -  Drawings 

R  S  5620  -  Facilities  -  Launcher  and  Platform  Characteristics 

OTHER  SUPPORT 


PI 

SC  R  S 

6000 

-  Other  Support 

R  S 

6010 

-  Other  Support 
Calibration 

PI 

R 

6020 

-  Other  Support 

Test  Instrument  Maintenance  and 
Requirements  for  Support  Agencies 


I 
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APPENDIX  B 


DESIGNATIONS  FOR  UOS  SUBSCRIBER  AGENCIES 


AGENCY  ALPHABETICAL  AGENCY 

ACRONYM  CODE 


WSMR 

A 

LeRC 

B 

NWS 

C 

DOD 

D 

ESMC 

E 

AFFTC 

F 

GSFC 

G 

MSFC 

H 

LaRC 

I 

JPL 

J 

KSC 

K 

NWC 

L 

ARC 

M 

PMTC 

N 

NOMTS 

0 

MSD 

P 

WFF 

Q 

ERDC 

R 

CSTC 

S 

JSC 

T 

ASDC 

U 

USAKA 

V 

WSMC 

w 

DFRF 

X 

NASA 

Y 

WSTF 

z 

AFWL 

AA 

ARMTE 

AB 

UTTR 

AC 

YPG 

AD 

AFWTF 

AE 

TFWC 

AF 

NATC 

AG 

AFOTEC 

AH 

PMRF 

AJ 

CSOC 

AS 

White  Sands  Missile  Range,  NM 
Lewis  Research  Center,  Cleveland,  OH 
National  Weather  Service,  Washington,  DC 
Department  of  Defense,  The  Pentagon 
Eastern  Space  and  Missile  Center,  Patrick  AFB,  FL 
Air  Force  Flight  Test  Center,  Edwards  AFB,  CA 
Goddard  Space  Flight  Center,  Greenbelt,  MD 
Marshall  Space  Flight  Center,  Redstone  Arsenal,  AL 
Langley  Research  Center,  Hampton,  VA 
Jet  Propulsion  Laboratory,  Pasadena,  CA 
Kennedy  Space  Center,  Cape  Canaveral,  FL 
Naval  Weapons  Center,  China  Lake,  CA 
Ames  Research  Center,  Moffett  Field,  CA 
Pacific  Missile  Test  Center,  Point  Mugu,  CA 
Naval  Ordnance  Missile  Test  Station,  WSMR,  NM 
Munitions  Systems  Division,  Eglin  AFB,  FL 
Wallops  Flight  Facility,  Wallops  Island,  VA 
Electronics  Research  and  Development  Command, 

Fort  Monmouth,  NJ 

Consolidated  Space  Test  Center,  Onizuka  AFB,  CA 
Johnson  Space  Center,  Houston,  TX 
U.S.  Army  Strategic  Defense  Command,  Washington,  DC 
U.S.  Army  Kwajalein  Atoll,  Marshall  Islands 
Western  Space  and  Missile  Center,  Vandenberg  AFB,  CA 
Dryden  Flight  Research  Facility,  Edwards  AFB,  CA 
National  Aeronautics  Space  Administration 
Headquarters,  Washington,  DC 
JSC  White  Sands  Test  Facility,  WSMR,  NM 
Air  Force  Weapons  Laboratory,  Albuquerque,  NM 
Army  Materiel  Test  and  Evaluation  Command,  WSMR,  NM 
Utah  Test  and  Training  Range,  Hill  AFB,  UT 
Yuma  Proving  Ground,  Yuma,  AZ 
Atlantic  Fleet  Weapons  Training  Facility, 

Roosevelt  Roads,  Puerto  Rico 
Tactical  Fighter  Weapons  Center,  Nellis  AFB,  NV 
Naval  Air  Test  Center,  Patuxent  River,  MD 
Air  Force  Operational  Test  and  Evaluation  Center, 
Vandenberg  AFB,  CA 
Pacific  Missile  Range  Facility, 

Barking  Sands,  Kauai,  HI 

Consolidated  Space  Operations  Center,  Falcon  AFS,  CO 


NOTE:  For  additions  or  deletions  to  this  list,  contact  the  RCC  Secretariat  at 
(505)  678-1107/1108,  Autovon  258-1107/1108. 
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